The prior art discloses radio communication circuits which permit client applications to be integrated.
Purely by way of illustration, the disadvantages of the prior art are presented below in the case where the radio communication circuit is an electronic radio communication module. This concerns for example a module from the “WISMO” family (registered trade mark) which uses the “Open AT” concept (registered trade mark) of WAVECOM (the party which registered the present patent application). It is obvious that these disadvantages may be transposed to the case of the above-mentioned variant of the application.
According to a first known technique, no real time capacity is provided for the client application integrated into the radio communication module. Indeed, in a radio communication module, the execution of a radio communication software stack (GSM/GPRS stack for example) requires real time response times to interruptions from the radio part of the platform of this radio communication module (GSM/GPRS platform for example). If the module does not take into account this interruption within a very limited time, it loses the synchronization with the network. Consequently, the module is no longer able to make/receive calls, send/receive SMS, USSD . . .
As a reminder, and in the specific case of a GSM/GPRS stack, it is essential to ensure that it operates correctly in the following modes:
disconnected: the module is not connected to the GSM/GPRS network and therefore may not make any communications;
rest (IDLE): the module is connected to the GSM/GPRS network. It is therefore able to receive or make calls, send/receive SMS messages or start a GPRS connection, but it does not use any of these possibilities,
connected: the module makes/receives calls,
send/receive SMS/USSD,
GPRS transfer: the module sends/receives data on the GPRS connection,
searching for the network: the module has lost the synchronization with the network (switching on/zone not covered) but is searching for a network to synchronize.
As it is not known what the impact of the execution of the client application processes will have on the operation of their own radio communication software stack and therefore on the overall operation of their product, the radio communication module manufacturers (especially those aimed at the M2M and automobile markets) do not provide their clients with the capacity to integrate processes whose execution in real time is critical for the correct operation of the finished product.
According to a second known technique, the suppliers of radio communication software stacks (GSM/GPRS/EDGE/3G stacks for example) provide a code which compiled and executed on an associated platform (GSM/GPRS platform for example) permits calls to be made/received . . . These software solution providers thus permit their clients to execute a very low level code, a code which could therefore allow processes to be integrated whose real time execution is critical. However under no circumstances do they then guarantee that the radio communication software stack will operate correctly. Furthermore, this implies a very complex design of the client application and consequently a very high level of expertise in the field of radio communications (GSM/GPRS for example).
For these reasons, this second alternative technique is difficult to use, especially by clients in the M2M markets and even more so by anyone who is not an expert both in the fields of the final application of the overall product and in the field of telecommunications, especially GSM/GPRS technologies.
Consequently, the majority of the software architectures that permit external code to be integrated onto a radio communication platform (Wireless platform) comply with the first known technique and are defined as described by FIG. 1. This software architecture typically comprises a radio communication software stack (in the example of FIG. 1, a GSM stack) comprising:
a radio communication interrupt manager 1 (“GSM Stack IT Handler”), which provides Physical Link Services) and provides the synchronization with GSM network. It is the GSM physical layer;
a set of tasks 2 specific to the GSM stack (GSM Stack Tasks L1-L3”), distributed in layers (L1 to L3), which provide a logical Link and Control Service. In the GSM standard, this corresponds to L1/L2/L3, RR/LAPD/MM/CCRLC/MAC/LLC/SNDCP/SM;
a set of tasks 3 related to AT commands (GSM AT Commands Task”), which provide a GSM stack control service. In the GSM standard, this corresponds to the Application layer; and
a task 4 called Idle Task which is executed when no other task uses the CPU resource.
This software architecture further comprises a client application 5 (in this example an Open AT application), comprising a set of client tasks. In the GSM stack, this client application 5 is positioned between the set of tasks related to AT commands and the idle task 4. The arrow ref. 6 shows an indicative reaction time scale (from approximately 1 ms up to approximately 10 ms). The arrow ref. 7 shows a priority level scale (from the idle task 4, which has the lowest priority, up to the radio communication interrupt manager 1, which has the highest priority).
This software architecture may also be broken down into two fields:
a field 8 for managing the interruptions, which comprises the radio communication interrupt manager 1; and
a field 9 for managing the tasks, which comprises all of the above-mentioned tasks (tasks 2 specific to the GSM stack, tasks 3 related to AT commands, idle task 4 and client application tasks 5).
Therefore, with this structure, any client application may be executed by the module whilst guaranteeing the correct operation of the GSM/GPRS stack. Nevertheless, no real time capacity may be guaranteed for this client application.
Currently, as illustrated in FIG. 2, a processor (not shown) inside the module 24 executes a main radio communication application 24 which manages the radio communication software stack (GSM stack for example). In order to overcome the absence of real time capacity for the client application 25 that is also executed by the module (by means of the internal processor mentioned above), it is necessary to use and install n the mother board 21 of the radio communication device, an additional processor 22 (for example a micro controller) and an additional memory 23, which are external to the radio communication module 24 and which allow client processes to be executed, for which real time execution is critical. Furthermore, in this example, the micro controller 22 is connected to a external device connector 26, via Input/Output interfaces for various uses (GPIOs) 27, SPT type (Serial Peripheral Interface) serial interfaces (SPI1, SPI2) 28 and 29, a USB interface 210 and a connection transporting the interruptions (IT) 211.
These additional elements (micro controller and memory) increase the complexity and manufacturing cost of the radio communication device.
There is therefore a need to offer a real time capacity for the client application executed by the module, in order to eliminate the need for an additional processor and an additional memory, external to the radio communication module.